-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QuickEdit: Add password field data to the pages quick edit #66567
QuickEdit: Add password field data to the pages quick edit #66567
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
) } | ||
{ hideLabelFromVision && ( | ||
<VisuallyHidden as="legend">{ label }</VisuallyHidden> | ||
) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a label for the top of the field, above the checkbox. This does cause a Password label to show twice when the checkbox is checked and the password field shows up.
Should we remove this and have it render without this label by default? ( cc: @jameskoster )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jameskoster, that sounds good, all done:
{ | ||
id: 'status_and_visibility', | ||
label: __( 'Status & Visibility' ), | ||
children: [ 'status', 'password' ].filter( ( child ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API for controlling visibility landed, but it didn't have support for combinedFields. We also have #66531 that aims to replace combinedFields API.
How would you like to move forward? Do we merge 66531 first and come back to this one later? Implement visibility for combinedFields as it is here? Any other approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this is ready, I would say merge this first, and replace the combinedFields
usage as part of #66531
I also rebased this PR and made use of the isVisible
function.
import PasswordEdit from './edit'; | ||
|
||
const passwordField: Field< BasePost > = { | ||
id: 'password', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this field type? I presume text
. We should make the type
mandatory at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes text
would be the most appropriate. I added this as part of this commit: 0f1b2dd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although given this is a password, I wonder if we should add support for a new type to manage hidden texts? Something like hidden-text
.
While the password is just plain text in the actual field, I wonder if we should display it as hidden when shown in a table? ( with maybe a tooltip or show button to display it ).
cc: @jameskoster if this could be of benefit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a sensible thought. I think text
is good for now because the field is not visible in any place other than QuickEdit.
hideLabelFromVision, | ||
}: DataFormControlProps< BasePost > ) { | ||
const { label } = field; | ||
const [ showPassword, setShowPassword ] = useState( !! data.password ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I think we should favor access to data via field.getValue( data )
, otherwise we may be replicating the getValue
logic in multiple places (not the case here, but I believe that should be a good practice for us). I was having a related conversation with @gigitux about passing field
to the View component for the same reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call out, I replaced it to use getValue
instead in this commit: 770c200
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pre-approving this one, though there's this design feedback to address. It also needs rebasing from trunk
.
I've also shared a question about a few moving pieces (but I'm fine shipping this first).
f896b7b
to
02b8eb0
Compare
isVisible: ( item ) => item.status !== 'private', | ||
}; | ||
|
||
export default passwordField; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a bit of JSDoc for this export, so it shows up in the docs (README) instead of "undocumented declaration"? (see parentField example)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup will do, one minute :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: 6abc19e
field, | ||
}: DataFormControlProps< BasePost > ) { | ||
const [ showPassword, setShowPassword ] = useState( | ||
!! field.getValue( { item: data } ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a nice detail, thanks.
@@ -7,3 +7,10 @@ | |||
justify-content: center; | |||
} | |||
} | |||
|
|||
.dataforms-layouts-panel__field-dropdown { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these styles be part of the dataviews/fields package instead? There's probably more places where we're doing this wrong, but DataViews specific classes shouldn't be used by consumers. They are not public API and can change without notice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not opposed to moving it to the password field specifically, there was two main reasons I end up doing it here:
- Given the line is only relevant within the panel view in the status dropdown, it felled more like a higher level managed style.
- I didn't want to make it the default for DataViews because of this previous conversation around combined fields
Having said that, I can add the same CSS to the password field specifically, so it is still panel specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm, I see your point. We need the combination of panel + field. These styles could live in edit-site
(current), dataviews
(but then would have wordpress field specific styles), or fields
(but then would have dataviews-specific styles). None of the three options is ideal. Let's leave it as it is and keep an eye for similar things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@louwie17 had a thought I wanted to share: what is this border for? is it for separating fields that are combined, like status & password are? If so, what if we refactor this to add the border automatically in that situation?
Co-authored-by: louwie17 <[email protected]> Co-authored-by: jameskoster <[email protected]> Co-authored-by: oandregal <[email protected]>
What?
This adds a password field to the
@wordpress/fields
package for use within the DataForm component. In particular the page quick edit.Related issue #64519.
Why?
The password field was missing from the page quick edit.
How?
A new password field is added to the
@wordpress/fields
component, which can be imported by usingpasswordField
.The field it-self is mimicked from the current implementation in the site editor sidebar:
gutenberg/packages/editor/src/components/post-status/index.js
Lines 222 to 263 in 2943dd3
Class names have just been updated.
The password field is displayed within the status dropdown as part of the combined fields API.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast